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SYSTEM AND METHOD FOR 
TRANSPARENTLY REGISTERING AND 
UPDATING INFORMATION OVER THE 
INTERNET 

BACKGROUND OF THE INVENTION 

1. Field of the Inveotion 

The present invention relates to the field of computing. 
More particularly, the present invention relates to a system 
and a method for accessing and downloading information 
from an online database. 

2. Description of the Related Art 

With the multitude of Internet service providers (ISPs) 
available to a user, it is difficult to create an Internet hybrid 
application (a client/server application that accesses infor- 
mation located on the Internet, or an IP-based computer 
network) that allows convenient and transparent access to 
data that is located at an Internet web site through any one 
of the multitude of ISPs so that data used by the application 
can be updated or augmented. Previously, this difficulty has 
been overcome by one of two approaches. First, update data 
for an application has been hosted at a selected service 
provider site and has been offered to subscribers of that 
particular Internet service. The hybrid application using the 
update data is then designed to interface with only that 
specific service provider. This approach has the drawback 
that users of the application are forced to be subscribers of 
the specific Internet service, thus limiting the number of 
users for which the application is suitable. The other 
approach has been to allow an application user to manually 
retrieve update data off the Internet. This approach has 
serious drawbacks because there are a number of ways 
errors can be made when the update data is downloaded, 
including downloading the data into an incorrect directory 
and downloading undesired data. 

Creating Internet hybrid applications that access the 
Internet, or any other IP-based computer network, can also 
be a complex task for an application developer. Since 
Internet service providers each have a proprietary way of 
interfacing with their software, there is no standard interface 
available to deal with multiple Internet service providers. 
Specific steps are required for connecting to the Internet, 
disconnecting from the Internet, verifying online status, 
downloading file s, etc. 

What is needed is a client/server application interface that 
allows application programmers to easily create Internet 
hybrid applications that allow users to use their preferred 
Internet service provider with a standard application pro- 
grammer's interface (API) for obtaining a convenient seam- 
less cormection to the Internet for communicating with an 
online site, such as for registering with the online server site 
and receiving data for augmenting static information pro- 
vided with the media of the client application with online 
resources. 

SUMMARY OF THE INVENTION 

The present invention provides a client/server application 
an interface that allows programmers to easily create appli- 
cations that allow users to use their preferred Internet service 
provider for obtaining a convenient seamless connection to 
the Internet for communication with an online site. The 
access methods provided to the application programmer are 
consistent for each supported Internet service provider, and 
allow for immediate expansion to include new service 
providers at any time. The present invention also provides a 
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transparent information exchange processes to handle the 
exchange of data, such as registration, identification, or any 
other desired information, with the online server site, in 
addition to transparently receiving data from the online 

5 server site for augmenting static information provided with 
the media of the client application. In this regard, the present 
invention includes a server computer connected to an 
IP-based computer network, such as the Internet. The server 
computer includes a server memory that stores token handler 

JO instructions, and a server processor that is connected to the 
server memory and is responsive to the token handler 
instructions. A client computer that communicates with the 
server computer includes a client memory and a client 
processor. The client memory, which can include a storage 

J 5 device and/or CD-ROM, stores client application instruc- 
tions that include a set of dynamic link libraries of code and 
information for each of a plurality of Internet service pro- 
viders. The client processor is connected to the client 
memory and is responsive to the client application instruc- 

2Q tions by estabhshing a connection with the server computer 
over the Internet through a selected Internet service provider 
and sending the token to the server computer. According to 
the invention, the connection to the Internet through the 
selected Internet service provider is based on a set of 

25 dynamic link libraries of code and information for the 
selected Internet service provider. The dynamic link libraries 
contain a detailed set of commands and information 
designed to allow applications to be created and maintained 
across a multitude of Internet service providers. The design 

3Q of the dynamic link b"braries allow for expansion to support 
new service providers by simply adding additional support 
dynamic link libraries for any Internet service provider. 

The present invention also provides a method for access- 
ing online information. According to the invention, token 

35 handler instructions are stored in a server memory of a 
server computer connected to the Internet, while client 
application instructions used to create, transmit, and receive 
tokens are stored in a client memory at a client computer. 
The chent application instructions include a set of dynamic 

40 link libraries of code and information for each of a plurality 
of Internet service providers. An loteraet service provider is 
selected from the plurality of Internet service providers and 
a connection with the server computer is established over the 
Internet through the selected Internet service provider. The 

45 connection through the selected Internet service provider is 
based on a set of dynamic link libraries of code and 
information for the selected Internet service provider. A 
token is sent to the server computer over the Internet and 
received at the server computer. The server computer then 

50 processes the token based on the token handler instructions 
stored in the server memory. 

The token sent to the server computer contains data 
relating to user registration information, user identification 
information, object request information, and/or actions to be 

55 executed by the server. The server computer responds to user 
registration information by entering the user registration 
information into a user database. When the token contains 
user identification information, the server processor vali- 
dates the user identification information, and when the token 

60 contains object request information, the server processor 
accesses a database for the object and sends the object to the 
client computer Preferably, the client computer graphically 
displays the status of the object requested while the object is 
being sent from the host computer to the client computer. 

65 According to the invention, a native formal token of the 
client application is converted into a URL-encoded format 
token and the URL-encoded format token is preferably 
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converted into a request in hypertext transfer protocol 
(HTTP) that is sent to the server computer. Alternatively, the 
URL-encoded format token can be converted into a req uest 
t hat is formatted in another protocol su ch as File Transfer 
Protocol (FIT), Mail, TebgL Gopher, Network News Trans- 5 
port Protocol (NNTP)(^^ and Forums. 

BRIEF DESCRIPTION OF THE DRAWING 

The present invention is illustrated by way of example 
and not limitation in the accompanying figures in which like 
reference numerals indicate similar elements and in which: 

FIG. 1 shows an Open System Interconnection (OSI) 
architectural hierarchy diagram of a client/server application 
incorporating the present invention; 

FIG. 2A shows a diagram of the relationship between a 
client/server application incorporating the present invention 
and online server resources connected to the Internet; 

FIG. 2B is a schematic block diagram of a client computer 
running a client application according to the present inven- 20 
tion connected to a server site on the Internet; 

FIG. 2C shows an exemplary graphical display of status 
of an object request; 

FIG. 3 is a functional block diagram showing an overview 
of information flow for an object request operation accord- 
ing to the present invention; 

FIG. 4 shows a flow diagram for an online object request 
operation according to the present invention; 

FIG, 5 shows intermediate steps of a process for gener- 30 
ating an exemplary registration token according to the 
present invention; 

FIG. 6 shows a flow diagram for an online registration 
operation showing client and server interaction according to 
the present invention; 35 

FIG. 7 shows a flow diagram for a preferred communi- 
cation process flow according to the present invention; 

FIG. 8 shows a flow diagram for an alternative commu- 
nication process flow according to the present invention; ^ 

FIG. 9 shows a flow diagram for an online update 
operation according to the present invention; and 

FIG. 10 is an architectural hierarchy diagram showing 
details a nd location of the layers, as related to the client 
system components, of the present invention. 45 

DETAILED DESCRIPTION OF THE 
INVENTION 

To facilitate a common interface for allowing a client/ 
server application access to information on the Internet, 50 
regardless of the Internet service provider (ISP) used, the 
present invention provides an interface permitting Transpar- 
ent Registration, Update and Exchange of data features 
using the Internet Protocol (TRUE/IP). That is, the present 
invention provides a standard interface for a client/server 55 
application, such as a CD-RO M/Intemet hybrid application, 
for connecting to an online server site f or augmenting s tatic 
c lient application material with dyp a mic online informa tion 
c ontained at the onlin e server site. The transparent interface 
protocol of the present invention permits convenient inter- 60 
action with an online server site, such as for receiving 
requested information, receiving any new information nec- 
essary for operation of the apphcation, for logging any 
information transfer, and for closing the connection when 
desired. 55 

The Internet service providers for which the present 
invention is compatible have the ability to launch their ISP 



access software with minimal user interaction, such as a 
password being entered once or once per session, to operate 
with a browser that can be opened to a specific uniform 
resource locator (URL), and/or to operate with any mnneling 
application or protocol for allowing access to a web site via 
a URL and for downloading files in response to client 
application requests. Examples of currently available Inter- 
net service providers providing these abilities are the IBM'^" 
Global Network, America Online™, CompuServe"^" and 
direct Internet connections. A generic Internet dialer can also 
be used for supporting unlisted ISPs, but this type of ISP 
forces a user to manually establish a connection with the ISP. 

A standard architecture for any computer-to-computer 
communication is illustrated by the Open System Intercon- 
nection (OSI) model that has been standardized by the 
International Standardization Organization (ISO). FIG. 1 
shows an OSI architectural hierarchy of layers mapped onto 
corresponding functional implementations of a client/server 
application incorporating the present invention. 

Layer 1 of the OSI hierarchy is the physical layer. In 
relationship to a user, this layer corresponds to client and 
server hardware, and an operating system, and relates to 
electrical, mechanical and functional controls of data cir- 
cuits. Layer 2 of the OSI model, the data link layer, deals 
with procedures and protocols for operating communication 
lines, and detecting and correcting message errors. For the 
present invention, this layer preferably conforms to the 
Transmission Control Protocol/Internet Protocol (TCP/IP). 
Layer 3, the network layer, corresponds to a communication' 
stack of an Internet service provider for the present inven- 
tion. In relationship to a user, this particular layer is con- 
cerned with how data is transferred between computers and 
deals with routing within and between individual networks. 

Layer 4, the OSI transport layer, is concerned with 
definition of rules for information exchange and manage- 
ment, of end-to-end delivery of information within and 
between networks, including error recovery and flow con- 
trol. For the pff^nt invention, this layer of the model 



prefe rably conforms to the Hypertext Tran sfer Protocol 
THTT ^/The TRUE/IP protocol of the present ipventio n also 



su pports any o t h e r IP-ba sed protocol, such as File Transfer 
Protocol (Fl pJT'ivIail, lelngj,^pher, Network News Trans- 
port Protocol (NNTP),^S) Forums, etc. Layer 5, the 
"session layer, handles dialog management and controls use 
of the basic communications provided by the transport layer. 
Layer 5 is the layer in which the present invention is 
preferably implemented by providing a code layer between 
an application and the code running an Internet service 
provider network. 

Layer 6 is the presentation layer of the OSI model and is 
concerned with masking differences between varying data 
formats, such as character codes, for providing transparent 
communications. For the present invention, this layer pref- 
erably uses a web server and comm on gateway interface 
( CGI) scrip ts. Layer / is tne application layer, and corre- 
sponds t o an application incorporating the present in vention, 
s uch as a CD-ROM application. 

FIG. 2Ais a diagram showing the relationship between a 
client/server application incorporating the present invention 
and online server resources connected to the Internet. In 
FIG. 2A, a clientMc^siLapplication 20 accesses an online 
server site using miUE^P)with or without a_ browser 2Qa , 
containing infomiaiion, such as any of types 21, 24 or 25, 
over the Internet 22 through an Internet service provider 
(ISP) 23. The Internet service provider can be any one of a 
plurality of Internet service providers. Client/server appli- 
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catioa 20 can be embodied as a client/server CD-ROM/ 
Internet hybrid application, for example. Information types 
21, 24 and 25 available on the online server each are 
accessible over the Internet and can include a host computer 
running a Hypertext Transfer Protocol (HTTP) server, such 
as an IBM''" Internet Connection Server. The host computer 
site runs p rocesses that provi de, for example, security and 
user validation, access to online files, databases and/or other 
information sources, and the ability to upgrade and expand 
client application 20 without dis tfi>>v*i"p; new isoft^ are. 

FIG. 2B shows a schematic block diagram of a client 
computer 30 running a client/server application according to 
the present invention connected to a server site 40 on the 
"nternet 37. Client computer 30 includes a processor 31 
connected to each of a memory 3 2, a storage device and/ or 15 
CD-ROM 33, an input device J4 and a display 35 m a 
well-known manner. Memory 32 includes instructions and 
information for the client application. Storage device and/or 
CD-ROM 33 can also include instructions and information 
for use by the client application. That is, storage device 20 
and/or CD-ROM 33 include a storage area having informa- 
tion that is readable by processor 31 and tangibly embodies 
a program of instructions executable by processor 31. Stor- 
age device 33 can be a hard drive or a ROM, for example. 
Input device 34, such as a keyboard and/or a mouse, accepts 25 
user inputs that are processed by processor 31 in accordance 
with the instructions and information for the client applica- 
tion stored in memory 32 and storage device and/or 



connecting with the online resource. When the user is 
finished interacting with the online resource and/or browsing 
the web, the user manually switches control back to the 
application. ^ 
The most interaction that a user may experience when a 
connection is made is a dialog from the ISP prompting the 
user for a user identification information and a password. 
The u gCT identification info rmation and password can be 
^glorel^yUhe-clienfapplicafion and~automatically passed to 
tETTSPAvhen a connection to the ISP is established. Since 
each ISP handles availability and receipt of user identifica- 
tion information and password information differently, this 
step in the connection process varies between providers^ 
accordingly. All other communications, such as data 
transfers, are reported to a user by a status bar and/or an 
animated icon appearing in the client applications interface 
so the user can visually verify that a transfer is occurring, 
and the approximate percentage of completion of the trans- 
fer. FIG. 2C shows an exemplary graphical disp lay 45 that 
is displayed on display 35 in FIG. 2B. GraphicalHisplay 45 
includes an exemplary status bar 46 and an exemplary 
animated icon 47 that communicate the status of a data 
transfer to a user. 

The information passed to an online resource site from an 
application incorporating the present invention are HTTP 
tokens containing information for gaining access to the 
online,resource.site-and-for_gaining-accessjojh£requested 
i nformation . There are three token types used by the present 
~D-ROM 33. Display 35 provides a visual interfare to client invention: a.ieg istration tok sn^-ao-id entifica t ion t o k rn a nd an 
computer 30 in^a well-known manner, such as by providing 30 object request token . A registration token is used the first 



a^graphical-user..interface_ (GUI) (FIG. 2C) in acco rdance 
wit h instruc tions and i nformation store d in memory TSl and 
storage device and/oTCD-ROM 33 for :he client application. 
Client computer 30 can include other components that are 
"not shown. 

Client computer 30 is connected to Internet 37 through 
Internet service provider 36, such as by a modem (not 
shown). Server system 40 is also connected to Internet 37 in 
a well-known manner. Server system 40 can be an internet 
protocol (IP) based computer network or a server site. In 
either case, server system 40 includes a processor 41 con- 
nected in a well-known manner to a memor y 42 and to a 
Hgtq base 4 3. Memory 42 stores instnictions/^such as scripts, 
and information that together provide token handlers for 



tokens received from Internet 37. Processor 41 uses the 45 information as a series of name=value pairs. The names and 



instructions and information stored in memory 42 to operate 
on received tokens in accordance with the appropriate token 
handler. For example, when an object request token is 
received and validated by the appropriate token handlers, 
processor 41 accesses database 43 in a well-known manner 
for retrieving the requested objected. Server system 40 can 
include other components that are not shown. 

There are two types of online resources that can be 
accessed by the present invention. For the first type of online 



time that a user connects to an online resource, or whenever 
registration information changes, such as when a new ISP is 
selected. An identification token is used the first time during 
each spssion that a user requests an online component, thus 
35 identifying the user to the online resource. A object request 
token is used for requesting objects from an online resource. 

A token containing information for transmission exists in 
a native format in the programming language structure used 
by the application, such as a C++ structure. Before 
40 transmission, the token is converted at the application level 
from a native format token into a token in a^URL-enco ded 
format. The URL portion of the encoded token determines 
the destination of the token and the server application that 
will process the token. The body of the token contains 



data types of the fields are coordinated between the client 
and the server applications. The application calls a series of 
TRUE/IP functions to create the URL and body of the token. 
The application passes the URL-encoded token to the 
50 TRUE/IP layer of the present invention for transmission. 
The TRUE/IP layer converts the URL-encoded token into a 
Hypertext Transfer Protocol (HTTP) request token using an 
HTTP POST method for transmitting the name=avalue pairs 
as a data body to the online resource. The data body is a 



resource, the client application automatically contacts a 55 specified number of bytes in the logical data stream follow- 
specific online server site resource a s a^ackgrQ u5d:TO2£gss 
under control of the application. Preferably, the online server 
site provides user authentication services and file storage. 

ruser verification, data is transferred from the online 
site to the application and is stored in specified directories 60 
un der control of the .application . The connection to the 
online site is always under the control of the application. For 
"Ee second type of onlinej gsource, the application launches 

a web browser as a foreground process for accessing a 

specific online server site. When the web browser is 65 pro vides obiea path informatiQiL,from iocaLfiles and g en- 
launched, a uniform resource locator (URL) information and cra tes TRUE/IP function calls . The TRUE/IP calls generate 
any other required connection parameters are passed for object request tokens i05. llie object request tokens 305 are 



ing the request header. Other information, such as user < 
identification and password information, is transmitted using 
HTTP request header fields that are generated byJRUE/IP 
fu nction c alls. 

FIG. 3 is a functional block diagram showing an overview 
of information flow for an object request operation accord- 
ing to the present invention;Jnn2,.ia client application 
300 communicates with a( ^ebserver3^ through a TRU E/ 
I P layer 301 of the present invention . Client application 300 
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iransfonned into HTTP POST request 306 by TRUE/IP layer 
301. StandardJ i JTP hea der fields are used for handli ng user 
authenticatton. client~ldentitication. timc-to-live. and other 
importanl^as pects Qf_clie Dt/s€rver communications. Other 
token informatio n is passed -asjiaiii e-value p airs in the body 
ofj^HTTP post requestj^lient applicat ion sends to a se rver. 
The HTTP POST requests 306 are sent to web server 302. 
Web server 302 includes a token handler 303 and a user 
database ,304. Token handler 303 is an application that 
processes common gateway interface (CGI) scripts written 
|n Perl 5, for example. CGI scripts receive tokens 306, act 
on the input data by, for example, retrieving requested data 
from a relational database 304, and return a response 308 as 
an HTTP response header and an optional response body to 
client application 300. TRUE/IP layer 301 converts the 
HTTP respo nse to the requested objects 307 - The first three 
characters of a response 308 contain an HTTP status code 
indicating that the online transaction was successful (HTTP 
status code 200) or that an enoneous input value or server- 
side error prevented the transaction from be completed (any 
HTTP status code greater than 299). The client application 
responds to each status code appropriately. 

FIG. 4 shows a flow diagram for an online object request 
process 400 according to the present invention. At step 401, 
the user reque sts an online-object . At step 402, the applica- 
tion determines whether it has been TRUE/IP protocol 
configured, that is, configured according to the invention for 
transparendy interfacing tojhe_oiiline.site4brQUglijLS£lected 
ISP. If the user has not configured the application with one 
of the available connection types and ISPs, any calls to 
connect to an online resource return a not configured-type 
error message and at step 403 the user is prompted to select 
and configure an ISP. If the ISP subscribed to by the user 
docs not support any outside control from other applications, 
the user is informed that the selected ISP is not supported by 
the present invention and is not compatible with pass- 
through Internet protocols. When the ISP is selected, the 
function will read all of the support Internet service provider 
dialer code dynamic link libraries (in the naming convention 
of DLR*.DLL) and return a text listing all of the ISPs each 
dynamic link library supports. This is then put into a dialog 
box for the user to select an ISP. Any information specific to 
an individual ISP is accessed through a "Configure" button 
provided on the ISP selection dialog. If an ISP docs not 
require any special settings, this button will be grayed out 
and is not available to be selected. To further facilitate a 
seamless- nature of the interface, each ISP module has an 
Autoconfigure function that attempts to gather as much 
information as possible by searching the operating system 
envirotunent and storage devices for ISP specific files and 
data. Flow then continues to step 404. 

If the application has_aLread y been TRUE/IP confi gured, 
the flow continues to step 404 where it is determined 
whether the client application is currently connected to the 
o nline site. If the application is not curr entl y connected, the 
application becomes conn ected at step::;^^"bv accessing the 
sery,er^t£throueh,th e-Selected ISP-a^d-flow continues to 
step 406. If the application is already connected to the online 
server site, flow continues to step 406 where it is determined 
whether the client application is being CQnnected-for-the-first 
ti me for the current sessio n. If not, flow continues to step 
407 where the client application sends a registration token, 
or an identification token, to the online site. Flow then 
continues to step 408. If the client application is not being 
connected for the first time for the current session, flow 
continues to step 408 where the object request token is sent 
to the online site. 



10 



An example in pseudocode showing of an object request 
token follows: 



// Create and initialize a request object 
pRequcstUrl - new CRequestUrl; 
// Assign the needed URL address to the remote host 
pRequcstUrl- > Url = needed URL address; 
// Assign the destination for the fUe to be placed on local system 
pRequcstUrl- > Destination = destination on local system; 
// If a custom callback is used, specify it 
pRequcstUrl- > CallbackFunction = custom callback function; 
// Oil CTruelp-RequcstUri with needed information 
CnYucIp::RequestUrl (pRequcstUrl); 
If RequcstUrlQ does not a return a success, 
perform error exception routines 



15 



20 



When a registration operation is performed, a registration 
token containing user identification information, such as a 
CD Key, a serial number from the CD-ROM packaging or 
another uniquely defined user identification, is used for 
registering the client application with the server site . FIG. 5 
shows intermediate stages m a process tor generating a 
registration token. User information, such as nanlT, addi^iiju 
etc., is initiaUy entered via a dialog box 50 during installa- 
tion oHh^a^glication^jor^?^^ 



30 



35 



50 



55 



60 



c onverted to a URL token at 51. The URL toke n is converted 
to an h lT F POST request at 52. A one-to-one association is 
the n established in a user registration da tabase at the online i 
res ource site betwee n_ear[Tjjsjer anH the user^s application- 
based ,on user identification information. 

The onhne server site has a registration token handler for 
processing registration information (handler 302 in FIG. 3). 
The example token handler does not require any special 
HTTP headers, because it uses CGI-type variables, such as 
the following name=value pairs: 
NAME_FIRST-user's first name 
NAME_MI=user's middle initial 
NAME„LAST-user's last name 
DOB=user's date of birth (yyyymmdd) 
NAME_ORG=name of the place where the product is 
installed 

ADDRESSl=first line of the user's street address 
ADDRESS2=second line of the user's street address 
CITY-user's city 

STArE=uscr's state or provincial abbreviation 
ZIPPLUS=user's ZIP or postal code 
COUNTRY-user's 2-3 letter country code (e.g., USA) 
ISP__USED=user's Internet Service Provider 
USERID^User Identification from the product 
In response to receiving a registration token, the example 

token handler returns one of the following HTTP status 

codes: 

201: The token handler succeeded in creating or updating 
the user record in the registration database. 

401: The token did not include a User ID, or the User ID 
was invalid. 

500: The token handler failed because of a database or 
other server-side error. 

Information gathered during an installation process, or aF 
any other time as specified by the client application, can be 
used for allowing a user to register an application electroni- 
cally with the^ online site. The gathered information is sent 
to the online server sit e as a re gi stration token when th e first 
request-fer-an-QBliDe^j ect is_processed. or du ripgunstal- 
lation oLthe-applicat ion, for examp lc,jQ.th e_case where a 
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registered user is re-installing the application, or modifying 
registration information, such as selecting a different ISP, the 
online account is re-established by, for example, re-entering 
registration information.-A.use r can also manuall y, register 
bv^ig glving user information to the online <«tr ver site by. 
for example, using a registratioa _card.^caIliD£-a-^ecified 
tel ephone number, or sendin g useLinformation viA-facsimile 
to a s pecified telephone number. The^ manually^upplied 
registratio n information is ^ h^" by thp. gfirv^r ^i^*^ whan 
the u ser accesses the site for the first tim e, 
^^ser identTfication information, or some other 
information, such as a CD -key, is included in a string that is 
sent to the online site when resources are requested. Each 
user can be assigned a password for gaining access to the 
online site and for user tracking purposes. The first time that 
a tiscr accesses an online site, a new account is created and 
associated with the user registration information. Subse- 
quent accesses to the online site can Jra£k_the_user_as a 
registered_user. 

^nrTshows a flow diagram for an online registration 
process 600 showing a client and server interaction. Process 
600 corresponds to step 407 of process 400. At step 601, it 
is determined whether the user desires to re^ster the cli ent 
apE^licatio n now or later . If later is desired, a flag is set at step 
602 allowing the use7 to register later. If registration is 
presently desired, it is determined whether the user infor- 
mation is available at step 603. If not, the user information 

f is gathered at step 604. If the user information is available, 
the appUcation connects to the online site at step 605. At step 
606, a regstration token is created and at step 607, the 

^reeist rationtoken is sent tome online site. At step 608, the 
registration token is received by the online site. At step 609, 
it is determined whether the user is already listed in a 
database. If not, a new user account is established at step 
610. At step 613 is it determine d whet her a new_user.account 
is succcssflilly establishTdrif not, an error message is sent to 
the client application at step 615, which is received by the 
client application at step 617. If the new user account-is 
successfully established, a success code message and any 
necessary files are sent to the user at step 616 and are 
received at step 617. 

If the user is listed in the database, the existing user 
account is updated at step 611. At step 612, it is determined 
whether the user account was successfufly updated. If not, 
an error code is sent to the client application at step 614 
which is received by the client application at step 617. If the 
user account was successfufly updated, a success code and 
any necessary files are sent at step 615 and received at step 
617. 

Apsuedocode example showing how a registration token 
is used foUows: 



// Create and initialize a request object 
pRequestUrl - new CRequestUrl; 

// Assign the registration URL address to the remote host 

pRequesturl- > Url = registration URL address; 

// Assign the destination for the file to be placed on local system 

pRcquestUrl- > Destination = destination on local system; 

// If a custom callback is used, specify it 

pRequestUrl- > CallbackFunction - custom callback function; 

// Assign name-value pairs to send to host 

pRequeslUrl- > SetName\feluePairs(USERID, User Identifkation 

information); 

pRcqucstUrl- > SctNamcV^lucPairsp^AME_FIRSr, user's first name); 
pRequestUrl- > SetNameV^luePairs(NAME_MI, user's middle initial); 
pRequestUrl- > SetName\^luePairs(NAME„LAST, user'6 last name); 
pRequestUrl- > SetNamc\^lucPairs(DOB, user's date of birth); 
pRequestUrl- > SctNameV^luePairs(NAME_ORG, user's organizalion); 



3,698 

10 

-continued 

pRequestUrl- > Set Name V^lue Pairs (ADDRES SI, user's address line 1); 

pRcqucstUrl- > SctNamc Value Pairs (ADDRESS2, user's address line 2); 

pRequestUrl- > SetNameV^lue Pairs (CnrY, user's dty); 
5 pRequestUrl- > SetNameV^lucPairs^ATE, user's state); 

pRequestUrl- > SetNameV%iluePairs(ZIPPLUS, user's zip code); 

pRequestUrl- > SetNameV^lue Pairs (COUNTRY, user's country>, 

pRequestUrl- > SetNameV^luePairs(ISP_USED, user's selected ISP); 

// Call CTrueIp::RequestLIrt with needed information 

CIYucIp : :RequcstUrI (pRequestUrl) ; 
\{) If RequestUrlQ does iK>t a return a success, 
perform error exception routines 



FIG. 7 shows a flow diagram for a preferred communi- 
cation process 700 a ccording to the present invention. At 

15 step TfiL 3 ^ser selects an online component from the 
application interface, such as a request for updated data. At 
step 702, it is determined whether the connection to the 
online resource is to be-by a dial-up connection or a direct 
connection to the Internet. If the connection is to be directly 

20 to the Internet rather than through a commercial ISP, flow 
proceeds to step 705. If a commercial ISP is to be dialed up, 
an online connection is initiated at step 703. At step 704, the 
user identification and password is sent to the ISP. At step 
705, it is determined whether the application is connected to 

25 the on line re source. If not, flow proceeds to step 706 where 
an error message is presented to the user. If the application 
is connected to the online resource at step 705, at step 707 
it is determined whether the current request is the first online 
transaction this session. If so, any initial files needed during 

30 program start-up are retrieved at step 711. Flow then pro- 
ceeds to step 708, where a resource request token for the 
desired object is sent. At step 709, the server response is ^ 
re ceiy edLaad_ stored in an appropriate direaory on the 
requesting s^em hard drive. At step 71U7~tlie us6r is 

35 prompted for whether the connection to the online resource 
should be closed. 

FIG. 8 shows a flow diagram for an alternative commu- 
nication process flow 800 according to the present invention 
that requires more user interaction than process 700. This 

40 situation would occur when the ISP of the user is not 
sup ported by the TRUE /IP l ayer of the present invention for 
launching the connection to the Internet, but still allows 
communications throug h normal H i i P c ommunications 
once a connection is established. Any connections to the 

45 Internet through the ISP software requires ma nual int erven- 
Jjj^^y ^ne use r. ' 

In either process 700 or 800, any communications are still 
apparent to the user by a status bar, animated icon, or any 
other indicator in the client appUcations interface allowing 

50 the user to see the status of a transfer taking place, and 
approximately how much of the transfer is complete. The 
present invention provides a default indicator shown in FIG. 
2C. 

At step 801 in FIG. 8, a user selects an online component 
55 fi-om the application interface. At step 802, it is determined 
that the selectcdJSE is not compatible with the TRUE/IP 
protocol of the present invention. At step 803, the user is 
informed to launch the dialer and connect to the ISP manu- 
ally. At step 804, the user switches to the dialer appUcation 
60 and connects to the ISP. Subsequently, the process flows 
through steps 707 to 711, which were describned in connec- 
tion with FIG. 7. 

When a disconnection from the Internet occurs because of 
inactivity time-out or some other ISP/operating system error 
65 in either process 70 0 . o r 8 ()fly th &»en iire process is repea ted 
the n ext time the user selcc ts_a n online resource^ from the 
client inLecface. 
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When a client application requires updating with code 
patches, or data updates, a request object function of the 
TRUE/IP protocol of the present invention can be used for 
retrieving a software module for automatically updating the 
application with little or no involvement of the user. The user 
is made aware that the update will take place, and is given 
the option for cancelUng the update. The update can retrieve 
an executable file that, when run, patches existing files, 
replaces files entirely, adds new files to the program, or any 
combination of these functions. 

FIG. 9 shows a flow diagram for an online update process 
900 according to the present invention. At step 901, a user 
selects an online object. At step 902, the client application is 
connected to a specified online site using, for example, 
connection process 700 or 800. At step 903, the object 
request is sent to the online site. At step 904, it is determined 
whether the user has a valid subscription listed in a database 
associated with the online site. If not, the request is rejected 
and an error message is returned at step 905. At step 906, the 
error message is displayed to the user. If the user has a valid 
subscription listed in the database, the user record is 
updated, if necessary, at step 907. At step 908, the requested 
object is sent to the user. At step 909, the object is received 
and run locally for automatically updating the files. 

An identification token is sent to an online resource from 
a client application the first time during a session that a user 
requests an online component so that the user is identified to 
the server. Any return file from the online server responding 
to the object request contains requested update files and the 
respective system data. Apsuedocode example showing how 
an identification token is used follows: 



// Create and initializB a request object 
pRequestUrl = new CRequestUrl; 

// Assign the identification URL address to the remote host 
pRcqucstUrl- > Url - identification URL address; 
// Assign the destination for the file to be placed on local system 
pRequestUrl- > Destination =» destination on local system; 
// If a custom callback is used, specify it 
pRequestUrl- > CallbackFunction = custom callback function; 
// Call CTrueIp::RequestUrt with needed information 
CTruelp: :RequestUrl (pRequestUrl); 
If RcqucstUrlQ docs not a return a success, 
perform error exception routines 



From the perspective of a client application programmer, 
the TRUE/IP protocol of the present invention provides a 
common coding interface that allows access to the Internet 
through any one of a plurality of Internet service providers. 
Thus, creation of an Internet-aware application is simplified 
because a client apphcation programme r is neithe rrequired 
to ^ understan d complicated co mmunication pro tocols, nor 
needs to deal with mu Iti lple'I^PnoFinteTfac in g tKr^ g 
respe ctive propjietary i nterfa ces. 

IFI'GT 10 is an architectural hierarchy diagram showing the 
layers of the present invention. The TRUE/IP protocol of the 
present invention uses Windows dynamic link libraries 
(DLLs) for transparently interfacing commands generated 
by the client application to commands used by an ISP, 
whether the ISP uses a point-to-point protocol (PPP) or a 
serial line Internet protocol (SUP) for communicating over 
the Internet. 

Modules are implemented for each Internet service pro- 
vider as a Windows dynamic link libraries (DLL) included 
with a cUenl application. Modules are shared among ISPs 
having common interfaces. The design of the MAIN.DLL 
allows for convenient addition of new ISPs, or updates of 
existing supported ISPs. A "null" DLL is provided as a 
default for indicating that no ISP has been selected. The 
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return values of all functions in the null DLL indicate that 
the ISP configuration has not been completed. Any configu- 
ration information gathered is stored in a TRUE1P.INI file 
for retrieval during configuration and initialization. A client 

5 application incorporating the present invention is also 
capable of providing a function for status having the capa- 
bility of interpreting percentage and fill status bar during a 
download transaction. Additionally, an application is 
capable of forming token structures, such as a registration 

10 token, an identification token, and an object request token, 
and providing all of the DLLs on a user's hard drive. 

The appUcation programmer interface for the present 
invention provides a main hea der file containin g all of the 
information necessary for a MAINDLL. A provider header 

15 is also included containing all of the information needed for 
each provider DLL. One header is used with all of the 
supported provider DLLs, allowing an ISP selected by a user 
to be used with the application function calls. 

The application programmer interface according to the 

20 present invention includes the exemplary commands listed 
below in a generalized format: 
CTruelp: : Configure 

Function: Presents a user with a list of supported ISPs from 
which the user selects for communication with an online 
25 site. 

Declaration: STATUS CTruelp: :Configure( ); 

Return Value: The Configure function returas a status value 

indicating whether the configuration was altered. 
Parameter: None 
30 Description: Configure( ) creates a list of available ISPs by 
accessing all support DLLs in the current directory. Each 
DLL is loaded and the entry point dIrInformation( ) is 
called. The returned information is the list of available 
ISPs and is presented to a user in a dialog. If the user 
35 selects an ISP from the list and chooses SAVE, the 
selected ISP DLLs are stored in the TRUEIP.INI file. The 
selected ISP DLLs are loaded and the entry point 
db-Configure( ) is called for performing an ISP specific 
configuration. If the user does not select an ISP from the 
40 list, the nuU ISP DLLs are automatically chosen. 
CTru6lp::Initiali2e 

Function: Prepares an ISP interface for use. 
Declaration: STATUS CTruelp: :Initialize( ); 
Return Value: The Initialize function returns a value indi- 
45 eating success or failure of a call to an ISP. 
Parameters: None 

Description: Initialize( ) is called in a session for preparing 
an ISP dialer module for use. The particular DLL is found 
by retrieving the DLL file name from theTRUEIRINI file. 
50 The entry points of the configured DLLs are loaded into 
memory. This is preferably performed upon starting the 
host application and after the user has modified the 
configured ISP. 

CTrueIp::RequestURL 
55 Fimction: Initiates a request for information from an online 
site. 

Declaration: STATUS CTruelp: :RequestURL(url string, 
path string, name-value pairs, pointer to callback 
function); 

50 Return Value: The RequestURL function returns a value 
indicating success or failure of the function call. 
Parameters: url: A string containing URL of the requested 
object. 

path: A string containing the fully qualified path name of 
65 the destination object. 

name-value: Variables and values added to the HTTP wrl 
string (optional). 
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callback: Function for displaying status of object transfer. 
If NULL, uses TRUE/IP default caUback. 

Description: RequestURL( ) is called for retrieving an object 
from an Internet server. The callback function pointer is 
used for sending stattis information to a client application, 
allowing the client application to use a custom display. (If 
NULL is specified for the callback function, the TOUE^P 
default callback is used). 

CTrueIp::Cancel 

Function: Cancels a request for information from an online 
site. 

Declaration: STATUS CrrueIp::Cancel(url string, url path); 
Return Value: The Cancel function returns a value indicating 

success or failure of the function call. 
Parameters: url: String containing URL of the requested 

object. 

path: String containing the fully qualified path name of 
the destination object. 

Description: Cancel( ) is called for halting a request being 
processed by RequestUrl( ). This will only remove the 
request indicated by the information in the cancel param- 
eters. If several requests are to be canceled, then 
Cancel( ) must be called for each operation to be halted. 

De fault CallbackFunction 

Function: Default callback function for displaying a stams 
dialog showing the progress of each requested object. 

Declaration: void DefaultCallbackFimction(url string, file 
size in bytes, total bytes received) 

Return Value: None 

Parameter: url: String containing URL of object requested, 
total file size: Total size of requested file in bytes, 
bytes received: Total number of bytes downloaded so far. 

Description: DefaultCallbackFunction( ) provides comple- 
tion information for the transfer being performed. A 
window is created and updated with each call. When all 
files are completed, the status display is be closed. 
This code is provided to an application programmer as an 

example of how to create a customized callback. 

CTrueIp::LaunchBrowser 

Function: Causes a dialer module for a selected ISP to start 

a web browser. 
Declaration: STATUS CTrueIp::LaunchBrowser(url string); 
Return Value: The LaunchBrowser fimction returns a value 

indicating success or failure of the function call. 
Parameter: url: Optional URL string for the page to be 

accessed by the browser on startup. If null, the browsers 

default home page is displayed. 
Description: LaunchBrowser( ) causes the ISP browser to be 

started. The optional url, if passed, specifies the page to 

display upon startup. If url is not passed, the default page 

of the browser is displayed. The command calls to the 

dlrLaunchBrowser( ) command, 
CTrueIp::IsConnected 

Function: Returns the status from a DLR support module of 

a host connection. 
Declaration: STATUS CTrueIp::IsConnccted( ); 
Return Value: The IsConnection function returns a value 

indicating success (connected/disconnected) or failure of 

a call. 
Parameter: none 

Description: IsConnected( ) calls to a selected ISPs dialer for 
learning whether a connection to a host is established. The 
command calls to the dlrIsConnected( ) command. 

CTrueIp::Connect 

Function: Called during a session for connecting to a con- 
figured ISR 
Declaration: STATUS CTrueIp::Coanect( ); 
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Return Value: The Connect function returns a value indicat- 
ing success or failure of a call. 
Parameters: None 

Description: Connect( ) establishes a connection with a 
5 selected ISR The command calls to the dIrConnect( ) 
command, 
CTruelp: : Disconnect 

Function: Called during a session for disconnecting from a 
configured ISP. 
10 Declaration: STATUS CTruelp: :Disconnect( ); 

Return Value: The Disconnect function remms a value 

indicating success or failure of a call. 
Parameters: None 

Description: Disco nnect( ) terminates a connection with a 
15 selected ISP. The command calls the dIrDisconnect( ) 
command. 
CTruelp; :SetAuthori2ationlnfo 

Function: Must be called once per session (before any 
communications occiu") for initializing an HTTP Autho- 
2Q rization header. 

Declaration: STATUS CTruelp ::SetAuthorizationInfo(user 
id string, user password string, realm string, host siring); 
Retum Value: The SetAuthorizationlnfo function returns a 
value indicating success or failure of the function call. 
25 Parameters: user id: String containing user identification 
(i.e., the CD-KEY) 

user password: String containing a user password (i.e., the 
CD-KEY) 

realm: String for identifying the realm defined on a host 
30 server (i.e., My_Server_Tokens) 

host: String for identifying the IP name of a host server 
(i.e., www.mysite.com) 
Description: SetAuthorizationInfo( ) initializes values used 
in the HTTP Authorization header for validating a user's 
35 access to host site files. 
CTrueIp::Close 

Function: Called once per session for terminating connec- 
tion with ISP dialer and support module. 

Declaration: STATUS CrrueIp::Close( ); 
40 Retum Value: The Qose function returns a value indicating 
success or failure of the function call. 

Parameters: None 

Description: Close( ) closes an active ISP dialer and support 
module, and cleans up any state information. 
45 The following exemplary functions are called by the 
exemplary TRUE/IP functions listed above. The functions 
below are specific to each ISP application programmer's 
interface. 

dlrConfigure Initiates a configuration dialog for a DLR 
50 application. Information gathered is stored in ISP specific 
locations in the TRUEIRINI file, 
dlrlnformation Returns descriptive information concerning a 

DLR interface. 
dlrlnitiaUze Sets information concerning a DLR interface. 
55 ispRequestUrl Requests file from a connected host. 

ispCancel Cancels a requested file transmission from a 

connected host. 
ispStatus Returns the status of the last operation performed 
by the ISP functions 
60 dhConnect Connects to a selected ISP. 

dlrlsConnected Checks the status of a connection to a host. 
dIrDisconnect Discormeas from a selected ISP, 
dkLaunchBrowser Launches an ISP specific web browser. 
ispSend Transmits a block of data to a specified port. 
65 ispReceive Receives a block of data from a specified port. 
The type STATUS is the retiun type from all functions 
calls. Any return code has a major (a TRUE/IP translated 
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code) and minor value, where the minor value has more The following code samples of a user authentication 

specific information regarding the major category value. The operation, a user registration operation and an online file 

return codes are listed in files associated with the TOUE/IR retrieval operation, written in Perl 5, illustrate how to create 

protocol of the present invention that are included-wiS a- ^^^^^^ handlers for performing various functions according 
client application. If available, text strings are returned with 5 ^^^^^ invention. Setup code and subroutines are not 

an error providme a detailed description 01 the reason for . . - *u - » * r 1 •* j u 

f „^ ■ . J -^u 1- * I- *• *i shown m all cases m the mterest of clarity and brevity, 

failure. Errors associated with a cuent apphcation token are _ ... - 1 r 

defined by a developer for each token sent by the client ^^'^^ ^^^'^ approaches for a user authentication 

application, A representative listing of exemplary return operation that selectively allows users access to online 

codes is as follows: information. For the first approach, the token handler can be 

TRUE/IP has not been configured; protected by the HTTP server so that a user name and 

TRUE/IP has not been initialized; password are required for entry. In this case, a client 

The specified file was not found; application tries to access a token handler, and the HTTP 

The URL transfer has been canceled; server responds with a status code 403 and includes a 
The host has broken connection without a valid HTTP 15 WWW-Authenticate header. The client application caUs the 

response header; and TRUE/IP SetAuthorizationInfo( ) function with a user name 

Not enough resources for remote connection. and password that are appropriate for the server and realm 

1^ The server-side of the TRUE/IP protocol of the present defined by the WWW-Authenticate header field, and then 

invention is preferably implemented as a collection of resends the token. 

common gateway interface (CGI) scripts for handfing com- second approach, the token handler provides its 

mun icatio DS between a client and a server under the HTTP own protection by checking an incoming token for an HTTP 

protocol^^Server-side TRUE/IP protocol applications can be Authorization header that has been created by the 

readily developed in any programming language/ SetAuthorizatioQlnfo( ) function. If the header does not 

environment that allows an input to be read from the exist, or if the information contained in the header is not 
Standard Input Stream (stdin), and allows an output to be ^5 valid, the token handler returns a status code 403 and a 

written to the Standard Output Stream (stdout) because such WWW-Authenticate header with the appropriate realm 

applications conform to the CGI specification. The name to the client application. The Authorization header 

pseudocode examples given below are in Perl 5, the most may be validated (after base-64 decoding) by a database 

popular language for developing CGI scripts. Other com- lookup or some other developer-defined identification sys- 

mon CGI scripting languages that can be used are, for tem. 

example, C/C++, TCL, Python and server-side Java. For the third approach, the token handler ignores the 

The full power and flexibility of the server-side aspect of Authorization header and requires certain name -value pairs 

the TRUE/IP protocol of the present invention is available to be present. The handling procedures are similar the 

when server applications are preferably executed in a non- second user authentication approadi. This approach is obvi- 

parsed-header (nph-) mode. The nph-mode allows server ated if the Authorization header handles a developer's 

scripts to respond to client requests by returning the full authentication requirements. 

range of HTTP status codes. Without nph-mode, scripts The following code fragment example shows the steps 

always return the HTTP success (status code 200). While needed for implementing the second user authentication 

status information can be placed elsewhere in a response approach, 
generated by the script, using nph-mode lets the script ^ 

transmit status information in the HTTP status fine, leaving 

the response body for providing data to the client. The !!g!g^;^ ^^Peri 

nph-mode may be enabled, depending on the HTTP server ^ nph-samplei 

software, by prefixing the name of server scripts with "nph-" # Sample token handler demonstrating user authentication 

or by storing the scripts in a special directory. - mmmmnt 

When a client/server communications system is defined ^} qwCstatidard); # load the CGi package 

1 1 • my $token = new CGI; # create object to hold token data 

using the TRUE/IP protocol of the present mvcntion, a ^^^^^ $pasj.word) - # decode and separate usermmc & password. 

developer specifies a set of tokens that will be passed from base64decode($EhfV{*HTTP-Autborization'}); ^ 

the client to the server, and the set of responses the server # ^ok up user & password (how is up to the developer . . .) 

will send back to the client. CGI scripts, caUed token unless &lookup($u3er, $password) { y 

, , , ^ 11 50 pnnt &hcadci<-status => '401 Unauthorized', 

handlers, are then wnlten to handle the tokens. Generally, .^yp^ 'text/plain'. 

the token handlers will have the same names as the tokens -www- Authenticate -> 'Basic realm - "aient_'Ibkea'"); 

they handle. For example, a registration token might be } 
handled by a token handler called registration (or, more 
likely, nph-registration). For each token and its handler, a 
developer specifies the following: 

a) The HTTP headers that are passed in the token from the For a user registration operation, the foUowing example 
client to the server, and the allowable values for each shows a token handler performing a registration operation, 
header. For this example, user information is entered in a database. 

b) The name-value pairs that are passed in the body of the go 

token. 

c) The HTTP status codes returned by the token handler. 
The status codes are selected for communicating cer- # aph-rcgistcr 

tain conditions, and preferably use standard HTTP #^^ken handler to register a user in a database 

status codes when available and appropriate. 55 use CGi qw(:standard); # load CGI package 

d) The contents of the token handler response, based on use DBI; # load database access package 
the returned status code. 



# Process the valid user's token 

# . . . 



#!Axsr/local/bin/perl 
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-continued 



my $token = new CGI; 

# Note how the token fields arc Q&mcd the same m the datJtb&sc columns 
my ©fields = qw(USERID NAME_FIRST NAME_MI NAME_LAST 

NAME_ORG ADDRESSl ADDRESS2 CITY STATE 
ZIPPLUS rSP„USED); 

my Sfield; 

my $got_reqd_fields = 1; 

# Check for required token fields 

for each Sfietd (qw(NAME_nRST NAME_LAST ZIPPLUS USERID)){ 
$got_reqd_fields & = $token- > param (Sfield); 

if ($eDt_rcqd_fields) { 
my $database = DBI- > coiinect(*my_database', 'dbadmin', 
*db_pas5Word') 

< I 
I I 

ifereturD_status(500, •Cculda*! comiect to registration database'); 

# Build the SQL Insert stetement It looks tike this: 

# INSERT INTO my_tablc 
(USERID^AME_nRST, . . . ^SP_USED) 

# VALUES ('JaneDoeUser%'Jane\ . . . / DLRW95.DLL') 

# except that Lt*s all in one long line, 
my $sql = 'INSERT INTO my_table ('; 
$sql .- join(*,', @fie]ds); 

$sql ') VALUES 

$sql join(',' grep(*"$toten- > param($_)"', ©fields)); 
$sql ')'; 

# Send the SQL to the database 
if (Sdatabase- > do($sql)) { 

&returQ_status(201, 'User Registered Successfully'); 
} else { 

&return_statiis(500, 'Couldn't insert user registration record*); 

} 

} else { 

&rctum_status(400, 'Required fields missing'); 

} 

aub return_status { 
my (Sstatus, $message) = @_; 
print header(-status =» $status, 

-type -> 'text/plain', 

-Con lent- length => lengthCSmessage)); 
print $message; 
exit(0); 

} 



For an online file retrieval operation, the following 
example code fragment shows how a token handler retrieves 
and returns to a client a file stored on the onhne server. The 
user authentication fragment above can be used for ensuring 
that only valid users retrieve files. This example returns a file 
from the onhne server file system. However, data can also be 
returned firom a database or similar information from 
another source. 



#!Aisr/local/bin/peri 

# nph-get_object 

# Sample token handler to process a Get_Object token. If the user's ID 

# is valid, the script copies the requested object back to the client 

# via STDOUT. 

use CGI qw(:standard); # load the CGI package 

my $token - new CGI; 

my %minic_typc = {'.gif ' => *imagc/gif 

'-iP8' 'image/jpeg', 

'.htm' -> 'text/html'}; 

# Validate the user ID passed in the HTTP-Authorization header 
my $user_auth = SENV{'HTrP_JlUraORI2AnON'}l | 

&retura_6tatus(401, 'Token must include Authorization header'); 
$uscr_auth = ~ m 1* Basic QA-Za-zO-9+/=»$|i; 
($user_id, Spassword) = splil(ry, &base64decode($l)); 
k (&valid_user($userid, Spassword)) { 

# get the object and send it back to the requester 
open(OBJ, (Spath = Stoken- > param('file_path'))) | | 

&retura„status(404, "Requested dbjcct ($path) is not accessible"); 

# Determine requested object MIME type 
($cxl) = C$path = - \\iw{3}$/); 
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-continued 

my $type = $mime_type{$ext}| | 'text/plain'; 

# Send the HTTP response header 
$num_bytes = -s Spath; 

5 print header(-status => '200 Document Follows', 

-type -> $type, 

-Content-length => $num_bytes); 

# Send the requested &le in the response body 
binmode(OBJ); 

while (<OBJ>) {print;} 
10 close(OBJ); 
} else { 

&rcturn_status(403. 'Invalid User XD/Passwoid'); 

} 



While the present invention has been described in con- 
nection with the illustrated embodiments, it will be appre- 
ciated and understood that modifications may be made 
without departing from the true spirit and scope of the 
invention. 

What is claimed is: 

1. A system for interfacing an application program in a 
computer with a selected one of a plurafity of ISPs on the 
Internet, comprising: 

a memory in the computer storing a cUent application in 
the OSl Apphcation Layer, said application providing a 
generic ISP accessing method as a native token format; 
a plurahty of ISP-specific dynamic link libraries of code 
in said memory, each storing details for accessing a 
respective one of a plurality of ISPs on the Internet; and 
an interface program in said memory in the OSI Session 
Layer transforming a token from said application in said 
native format into a URL-encoded object request token by 
taking details of a selected ISP from one of said plurality of 
ISP-specific dynamic link libraries, and passing said URL- 
encoded object request token to an output program in the 
OSI Transport Layer. 

2. A system comprising: 

a memory storing application instructions, the appUcation 
instructions including a chcnt application in the OSI 
Application Layer, said application providing a generic 
ISP accessing method as a native token format; 
a plurahty of ISP-specific dynamic link libraries of code 
in said memory, each storing details for accessing a 
respective one of a plurality of ISPs on the Internet; 

45 an interface program in said memory in the OSI Session 
Layer transforming a token from said application in 
said native format into a URL-encoded object request 
token by taking details of a selected ISP from one of 
said plurality of ISP -specific dynamic link libraries, 

50 and passing said URL-encoded object request token to 
an output program in the OSI Transport Layer; 
a processor connected to the memory and being respon- 
sive to the apphcation instructions establishing a con- 
nection with an online database through said selected 

55 ISR 

3. The system according to claim 2, wherein the memory 
includes at least one of a storage device and a CD-ROM. 

4. The system according to claim 3, wherein the onUne 
database is stored and accessed via a server that is coupled 

60 to the Internet. 

5. The system according to claim 4, wherein the onUne 
database is coupled to the Internet through an IP-based 
computer network. 

6. The system according to claim 4, wherein the processor 
65 is further responsive to the appUcation instmctions by con- 
verting the URL-encoded format token into a hypertext 
transfer protocol (HTTP) request. 
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7. The syste m accor diag to claim 4, wherein the processor 
isfiirtber re^onsive to the a^l ication"i^triictionrt5 \M[^ 
verting tHc~ irRIgncoded'format t oken into a token forin at- 
tedTD~arprotQCQiIsejected jLomiA-gimiBl coiisistin jg of File 
TransfeTTrotocol (FTP), Mail, TetecL Gopher, Network 
News Transport Protocol (NNTP),<^ha4 and Forums. 

8. The system according to claim 27nirther comprising a 
display showing status of the information retrieved from the 
online database. 

9. The system according to claim 8, wherein the display 
displays the status graphically. 

10. A system comprising: 

an IP-based computer network; 

a server computer coupled to the IP-based computer 
network and receiving a token from the IP-based com- 
puter network, the server computer including, 
a server memory storing token handler instructions for 

the token, and 
a server processor responsive to the token and the token 
handler instructions by processing the token; and 
a client computer including, 

a client memory storing client application instructions, 
the client application instructions including a set of 
dynamic link libraries of code and information for 
each of a plurality of IP-based computer network 
service providers, and 
an interface program in said memory in the OSI Ses- 
sion Layer transforming a token from said applica- 
tion in said native format into a URL-enooded object 
request token by taking details of a selected ISP from 
one of said plurality of ISP-specific dynamic link 
libraries, and passing said URL-encoded object 
request token to an output program in the OSI 
Transport Layer; 
a chent processor connected to the client memory, and 
being responsive to the client application instructions, 
cstabhshing a connection with the server computer over 
the IP-based computer network through a selected 
IP-based computer network service provider. 

11. The system according to claim 10, wherein the 
IP-based computer network is the Internet, and the selected 
IP-based computer network service provider is an Internet 
Service Provider. 

12. The system according to claim 11, wherein the server 
computer is coupled to the Internet through another IP-based 
computer network. 

13. The system according to claim 11, wherein the server 
computer further includes at least one database connected to 
the server processor, and 

wherein the token requests an object stored in one of the 
databases, 

the server processor being responsive to the token by 
accessing one of the databases for the object and 
sending the object to the client computer. 

14. The system according to claim 13, wherein the client 
computer further includes a display showing a status of the 
object sent to the chent computer. 

15. The system according to claim 13, wherein the display 
displays the status graphically. 

16. The system according to claim 10, wherein the client 
memory includes at least one of a storage device and a 
CD-ROM. 

17. The system according to claim 10, wherein the client 
processor is further responsive to the client application 
instructions by converting the URL-encoded format token 
into the token sent to the server computer, the token sent to 
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the server computer being a hypertext transfer protocol 
(HTTP) request. 

18. The system according to claim 10, wherein the client 
processor is further responsive to the chent appUcation 

5 instructions by converting the URL-encoded format token 
into the token sent to the server computer, the token sent to 
the server computer being f ormatted in ajprotoco l selected 
from a group consisting ofl'Ue Iranster Protocol (FTP), 
Mail, lelnfiL GopEer, Network News Transport Protocol 

10 (NNTP),(@t, and Fomms. 

19. A method of accessing online data comprising the 
steps of: 

storing application instructions in a memory, the applica- 
tion instructions including a a client application in the 
15 OSI ApphcatioQ Layer, said application providing a 
generic ISP accessing method as a native token format; 

storing a plurality of dynamic link hbraries of code in said 
memory, each storing details for accessing a respective 
one of a plurality of ISPs on the Internet; 
20 selecting an Internet service provider from the plurality of 
Internet service providers; 

converting a native format token of the application into a 
URL-encoded object request token by taking details of 
a selected ISP from one of said plurality of ISP-specific 
dynamic link hbraries, and passing said URL-encoded 
object request token to an output program in the OSI 
Transport Layer; data; 

establishing a connection with an online database through 
the selected Internet service provider; and 

retrieving information from the online database. 

20. The method according to claim 19, wherein the 
memory includes at least one of a storage device and 
CD-ROM. 

21. The method according to claim 20, wherein the online 
database is a node on the Internet. 

22. The method according to claim 19, further comprising 
the step of converting the URL-encoded format token into a 
hypertext transfer protocol (HTTP) request. 

^ 23. The method according to claim 19, further comprising 
the step of converting a URL-encoded format token into a 
token formatted in a protocol selected from the group 
consisting of File Transfer Protocol (FTP), Mail, T^et, 
Gopher, Network News Transport Protocol (NNTP)0Eai^ 

^5 and Forums. 

24. The method according to claim 19, further comprising 
the step of displaying a status of the information retrieved 
from the online database. 

25. The method according to claim 24, wherein the step 
of displaying the status displays the stams graphically, 

26. A method for accessing online information comprising 
the steps of: 

storing token handler instructions in a server memory of 
a server computer coupled to an IP-based computer 

5^ network; 

storing application instructions in a client memory at a 
client computer, the application instructions including a 
client application in the OSI Application Layer, said 
application providing a generic ISP accessing method 

gQ as a native token format; 

storing a plurality of dynamic link hbraries of code in said 
memory, each storing details for accessing a respective 
one of a plurality of plurahty of IP-based computer 
network service providers on the Internet; 

65 selecting an IP-based computer network service provider 
from the plurality of IP-based computer network ser- 
vice providers; 
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converting a native format token of the application into a 
URL-encoded object request token by taking details of 
a selected ISP from one of said plurality of ISP-specific 
dynamic link libraries, and passing said URL-encoded 



object request token to an output program in the OS I 5 ^^>k, and Forums. 



the token sent to the server computer, the token sent to a 
server computer being formatted in a protocol selected from 
the group consisting of File Transfer Protocol (FTP), Mail, 
Telnet, Gopher, Network News Transport Protocol (NNTP), 



IS 
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Transport Layer; data; 

establishing a connection with the server computer over 
the IP-based computer network through the selected 
IP-based computer network service provider, 

sending a token to the server computer over the IP-based 
computer network; 

receiving the token at the server computer; and 

processing the token based on the token handler instruc- 
tions stored in the server memory. 

27. The method according to claim 26, wherein the 
IP-based computer network is the Internet, and the selected 
IP-based computer network is an Internet service provider. 

28. The method according to claim 27, wherein the server 
computer is coupled to the Internet through another IP-based 
computer network. 

29. The method according to claim 27, wherein the token 
requests an object stored in a database connected to the 
server computer, the method further comprising the steps of: 

accessing the database for the object in response to the 25 
token; and 

sending the object to the client computer over the Internet. 

30. The method according to claim 27, wherein the token 
contains at least one of user registration information, iden- 
tification information, or other information, and 

the method further comprises the step of modifying a state 
of the server based on the information contained in the 
token. 

31. The method according to claim 30, wherein the token 
further contains a request for an object stored in the 
database, 

the method further comprising the steps of: 
accessing the database for the object in response to the 

token; and 
sending the object to the client computer. 

32. The method according to claim 31, further comprising 
the step of displaying a status of the object sent to the chent 
computer. 



^37. A program storage device comprising: 
a storage area; and 

information stored in the storage area, the information 
being readable by a machine, and tangibly embodying 
a program of instructions executable by the machine for 
performing method steps comprising: 
storing application instructions in a memory, the apphca- 
tion instructions including a client application in the 
OSI Application Layer, said application providing a 
generic ISP accessing method as a native token format; 
storing a plurality of dynamic link libraries of code in said 
memory, each storing details for accessing a respective 
one of a plurality of ISPs on the Internet; 
selecting an Internet service provider from the plurality of 

Internet service providers; 
converting a native format token of the application into a 
URL-encoded object request token by taking details of 
a selected ISP from one of said plurality of ISP-specific 
dynamic link libraries, and passing said URL-encoded 
object request token to an output program in the OSI 
Transport Layer; data; 
establishing a connection with an online database through 

the selected Internet service provider; and 
retrieving information firom the online database. 

38. The program storage device according to claim 37, 
wherein the memory includes at least one of a storage device 
and a CD-ROM. 

39. The program storage device according to claim 38, 
wherein the online database is a node on the Internet. 

40. The program storage device according to claim 37, 
wherein the method steps further comprise the step of 

40 converting the URL-encoded format token into a hypertext 
transfer protocol (HTTP) request. 

41. The program storage device according to claim 37, 
wherein the method further comprises the step of converting 
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the URL-encoded format token into a token formatted in a 

33. The method according to daim 32, wherein the status 45 protocol selected from a group consisting of File Transfer 
is displayed graphically. Protocol (FTP), Mail, Telnet, Gopher, Network News Trans- 

34. The method according to claim 26, wherein the chent port Protocol (NNTP), Chat, and Forums. 

memory includes at least one of a storage device and a 42. The program storage device according to claim 37, 

CD-ROM. wherein the method further comprises the step of displaying 

35. The method according to claim 26, fiirther comprising 50 a status of the in format ion retrieved from the onhne 



the step of converting the URL-encoded format token into 
the token sent to the server computer, the token sent to the 
server computer being a hypertext transfer protocol (HTTP) 
request. 

36. The method according to claim 26, further comprising 55 
the step of converting the URL-encoded format token into 



database, 

43. The program storage device according to claim 42, 
wherein the step of the method of displaying the status 
displays the status graphically. 



02/04/2004, EAST Version: 1.4.1 



